<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:th="http://www.thymeleaf.org" lang="en">

<head th:replace="fragments/headTag :: headTag">
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="description" content="" />
<meta name="author" content="" />
<title>BaseX Load Tool :: a beta tool with Spring and Thymeleaf</title>

<!-- Bootstrap -->
<link
	href="http://netdna.bootstrapcdn.com/bootstrap/3.0.3/css/bootstrap.css"
	th:href="@{/webjars/bootstrap/3.0.3/css/bootstrap.css}"
	rel="stylesheet" />
<link href="../../../resources/css/navbar.css"
	th:href="@{/resources/css/navbar.css}" rel="stylesheet" />
<!-- JQuery -->
<script
	src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"
	th:src="@{/webjars/jquery/1.9.0/jquery.min.js}"></script>
<script
	src="http://netdna.bootstrapcdn.com/twitter-bootstrap/3.0.3/js/bootstrap.min.js"
	th:src="@{/webjars/bootstrap/3.0.3/js/bootstrap.min.js}"></script>

<!-- Spring JS and Ajax -->
<script type="text/javascript" th:src="@{/resources/dojo/dojo.js}"></script>
<script type="text/javascript" th:src="@{/resources/spring/Spring.js}"></script>
<script type="text/javascript"
	th:src="@{/resources/spring/Spring-Dojo.js}"></script>
<!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
      <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
      <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
    <![endif]-->
</head>
<body>
	<div class="container">
		<div th:include="fragments/bodyHeader :: bodyHeader" th:remove="tag">This
			is the navigation bar here</div>
		<div class="panel panel-default">
			<div class="panel-heading">
				<h3 th:text="#{process.title}" class="panel-title">Tutorial</h3>
			</div>
			<div class="panel-body">
				<!-- Navigation Tabs -->
				<ul class="nav nav-tabs">
					<li class="active"><a th:text="#{process.tabs.tab1}"
						href="#col-intro" data-toggle="tab">Collection-level Template</a></li>
					<li><a th:text="#{process.tabs.tab2}" href="#file-intro"
						data-toggle="tab">File-level Template</a></li>
					<li><a th:text="#{process.tabs.tab3}" href="#example"
						data-toggle="tab">How-to</a></li>
				</ul>
				<div class="tab-content">
					<p></p>
					<div class="tab-pane fade in active" id="col-intro">
						<h4 th:text="#{process.page.title}">Walkthrough the QuDEx
							Repository Tools - Spreadsheet Builder</h4>
						<p th:text="#{process.text1}">This application eases the
							process of creating template spreadsheets containing the
							appropriate metadata headers to create both Qudex Collection and
							documents descriptions.</p>
						<h4 th:text="#{process.page.subtitle}">QuDex
							Collections/Sub-collections Spreadsheet</h4>
						<div>
							<p th:text="#{process.collection.text1}">When creating
								collection spreadsheets, two different types of information are
								provided. The first one relates to the collection structure,
								that is how the collection is organised. The second type of
								information relates to the research study as a whole
								(study-level documentation) and provides an overview of the
								research context and design; data collection methods; data
								preparation and results or findings for a particular study.</p>

							<p th:text="#{process.collection.text2}">The information
								related to the structure of the collection is provided in the
								spreadsheet itself, i.e. the collection structure can be
								hierarchical, or more flexible (for example a collection
								container, with no sub-collections or levels). A common scenario
								is to organise data in the form of hierarchical folders
								structure, in which a set of sub-collections belonging to the
								same level of the hierarchy are described and included in the
								same spreadsheet. The diagram below shows a sample collection
								structure in which there are two levels of sub-collections.</p>
							<img th:src="@{resources/img/doc/sample-col-structure.png}"
								class="img-responsive center-block" />
							<p th:utext="#{process.collection.text3}">Each level of the
								sub-collection will require a collection-level
								spreadsheet/template describing the different sub-collections
								for that particular level. That is, the container level template
								will include one entry describing the collection; level-1
								template will include three entries (one for &quot;project
								reports&quot;, another one for &quot;research data&quot;, and a
								third for &quot;documentation&quot;; and the level-2 template
								will incorporate two entries).</p>
							<p th:text="#{process.collection.text4}">The study-level
								information is provided in each collection spreadsheet by using
								metadata terms from a set of standard vocabularies (metadata
								schemas). More detailed contextial information can be specified
								by using a combination of elements from DDI and Dublin Core
								schemas (study documentation). The following table summarises
								the metadata elements that can be used when creating
								collection-level templates.</p>
							<table th:utext="#{process.collection.table}" class="table">
								<tr>
									<th>MD Schema</th>
									<th>Optional elements</th>
									<th>Compulsory elements</th>
								</tr>
								<tr>
									<td>Dublin Core</td>
									<td>description; language; identifier; subject; coverage;
										rights; contributor; type; creator; date; publisher</td>
									<td>title</td>
								</tr>
								<tr>
									<td>QuDEx</td>
									<td>deletePid; updatePid</td>
									<td>---</td>
								</tr>
								<tr>
									<td>GEO lat/long</td>
									<td>lat_long; location</td>
									<td>---</td>
								</tr>
								<tr>
									<td>RDF</td>
									<td>---</td>
									<td>type</td>
								</tr>
								<tr>
									<td>Skos</td>
									<td>note</td>
									<td>---</td>
								</tr>
								<tr>
									<td>DDI</td>
									<td>samplingProcedure; samplingProcedure; timeMethod;
										dataCollector; collectionMode</td>
									<td>---</td>
								</tr>
								<tr>
									<td>Fedora Rel</td>
									<td>isPartOf</td>
									<td>---</td>
								</tr>
							</table>
						</div>
						<p th:utext="#{process.text2}">A Collections/sub-collections
							spreadsheet will store multiple &quot;QuDex Instance
							Objects&quot; in Fedora (one per annotated row in the
							spreadsheet). This objects will hold their own metadata
							description fields and a special datastream which contains the
							XML version of the whole Qudex Instance. This XML instance is
							contructed from all the Qudex document objects associated with
							the Qudex Collection object, which are in the form of Fedora
							objects but transformed into XML fragments.</p>
					</div>
					<div class="tab-pane fade" id="file-intro">
						<h4 th:text="#{process.page.subtitle2}">QuDex Files
							Spreadsheet</h4>
						<p th:utext="#{process.text3}">This type of spreadsheet
							contains descriptions of &quot;QuDex Files&quot; that will be
							stored in Fedora as objects. Each of these files will be
							associated with an already existing Collection/Sub-collection
							object and will hold the following data:</p>
						<p th:text="#{process.file.text1}">File spreadsheets contain data-level documentation for the
							resources included in a collection. Three different types of
							information can be provided. The first type gives information
							about the data resources themselves, that is information such as
							title for the file, short description, keywords, creator - mostly
							information that can be described using Dublin Core terms - and
							physical information about the file that can be extracted
							automatically. Indeed, when uploading resource compressed files
							into the template builder application, the generated templates
							auto-populate such kinds of information. Examples of these
							include: file mime type, creation date, file size, geographical
							location (for images that use EXIF metadata), etc. The following
							table summarises the different metadata elements used in the
							templates to provide these kinds of information.</p>
						<table th:utext="#{process.file.table1}" class="table">
							<tr>
								<th>Metadata Schema</th>
								<th>Optional elements</th>
								<th>Required elements</th>
							</tr>
							<tr>
								<td>Dublin Core</td>
								<td>description; language; subject; coverage; source; title</td>
								<td>format; type; creator</td>
							</tr>
							<tr>
								<td>QuDEx</td>
								<td>isReferencedBy; labelCategory; isLinkedTo; labelMemo;
									isVersionOf; isFormatOf; isRelatedTo; labelCode; category;
									memo; isAnnotationOf; code</td>
								<td>---</td>
							</tr>
							<tr>
								<td>Fedora Rel</td>
								<td>isPartOf</td>
								<td>---</td>
							</tr>
							<tr>
								<td>GEO lat/long</td>
								<td>lat_long; location</td>
								<td>---</td>
							</tr>
							<tr>
								<td>RDF</td>
								<td>---</td>
								<td>type</td>
							</tr>
						</table>
						<p th:text="#{process.file.text2}">The second type of information is analytical information
							that applies to individual files within the collection. This kind
							of information is documented by using elements from the QuDEx
							schema. The following table summarises these elements and
							provides examples of use. Analytical information documentation
							was included in QuDEx originally to support the kinds of
							analytical information that is managed in CAQDAS packages.</p>
						<table th:utext="#{process.file.table2}" class="table">
							<tr>
								<th>Element</th>
								<th>Description</th>
								<th>Example</th>
							</tr>
							<tr>
								<td>labelCode</td>
								<td>The label of a qudex Code element. For this field
									user-friendly or comprehensive words associated with the codes
									should be used.</td>
								<td>In the following example, the values for labelCode
									should be the short sentences or words associated with a
									numerical code. See example 1.</td>
							</tr>
							<tr>
								<td>code</td>
								<td>The value of a qudex Code element. For this field the
									actual numerical code value should be used.</td>
								<td>In the following example, the values for labelCode
									should be the short sentences or words associated with a
									numerical code. See example 1.</td>
							</tr>
							<tr>
								<td>labelCategory</td>
								<td>The label of a qudex Category element (source QuDEx
									schema). The same as with labelCode.</td>
								<td>See category example 2.</td>
							</tr>
							<tr>
								<td>category</td>
								<td>The value of a qudex Category element. The same as with
									codes.</td>
								<td>See category example 2.</td>
							</tr>
							<tr>
								<td>labelMemo</td>
								<td>The label of a qudex Memo element.</td>
								<td>The title of the memo annotation.</td>
							</tr>
							<tr>
								<td>memo</td>
								<td>In QuDEx there are two ways of including memo
									annotations. The first is to include them as inline memos
									directly in the QuDEx instance. The second alternative is to
									refer to external memos that are in separate files (for example
									a text document) and then they are referenced in the QuDEx
									document.</td>
								<td>The templates only support the inclusion of inline
									memos, that is, they will be in textual form and included in
									the appropriate row cell in the template.</td>
							</tr>
							<tr>
								<td>isOriginal</td>
								<td>Custom element not included originally in QuDEx that is
									used to identify whether the resource will be stored in the
									repository or a reference to the original file will be stored
									instead, e.g. a URL that points to the location of the original
									file</td>
								<td>isOriginal=true means that the spreadsheet will contain
									a header called 'originalReference:R' which is interpreted as a
									link to an external resource that lives outside the repository;
									in contrast, isOriginal=false generates a header
									'sourceReference:M'. M and R qualifier are Fedora specific and
									refer to the type of datastream that will hold the resource
									being uploaded. M for managed (internal to the repository) and
									R for redirected (a reference to the original location is
									provided.)</td>
							</tr>
						</table>
						<h4 th:text="#{process.file.subtitle1}">Coding scheme and QuDEx elements example</h4>

						<p th:text="#{process.file.text3}">In this example the coding scheme is composed of a
							hierarchy of codes, expressed numerically. The numerical codes
							are the values that are documented with the 'code' element. Each
							numerical code has a short description attached to it, providing
							meaning to the code. The short description is normally either a
							short sentence (like in the example) or a word. The description
							of the code is then documented by using the 'labelCode' term.</p>
						<div class="well">
							<ol th:utext="#{process.file.list1}">
								<li>The smoking period
									<ol>
										<li>When started and stopped</li>
										<li>Reasons for starting smoking and continuing to smoke</li>
									</ol>
								</li>
								<li>Influences on smoking behaviour
									<ol>
										<li>Home environment</li>
										<li>Peers</li>
										<li>Work environment</li>
									</ol>
								</li>
							</ol>
							<p>
								<span th:text="#{process.file.link}">(source for the example:</span> <a
									href="http://www.uniteforsight.org/global-health-university/quantify-research">
									http://www.uniteforsight.org/global-health-university/quantify-research</a>)
							</p>

							<p th:utext="#{process.file.text4}">
								<strong>labelCode</strong> = Reasons for starting smoking and
								continuing to smoke
							</p>
							<p>
								<strong>code</strong> = 1.2
							</p>
						</div>
						<h4 th:utext="#{process.file.subtitle2}">Categories and QuDEx elements example</h4>
						<p th:utext="#{process.file.text8}">The mechanics for expressing categories is very similar to
							the ones for codes. The main difference lies on the explicit
							management of hierarchies for categories. For codes, there is no
							explicit way of expressing the hierarchy (when working with a
							hierarchical coding scheme), therefore they won't be displayed as
							a hierarchical tree when visualising them in the Collection
							Viewer. In contrast, for categories there is a mechanism to
							express the hierarchy in the template spreadsheet. The way of
							expressing the hierarchy is as follows:</p>
						<div class="well" th:utext="#{process.file.text5}">
							<p>Let's use as an example for categories 'Sex' and
								sub-categories 'Male' and 'Female'.</p>
							<ul>
								<li>Sex
									<ul>
										<li>Male</li>
										<li>Female</li>
									</ul>
								</li>
							</ul>

							<p>Each element within the category hierarchy or tree has to
								be represented by its full path. The different levels of the
								hierarchy are specified by using the character ':' (colon). The
								values for the categories are S for sex; M for male and F for
								female; and the labels (labelCategory) are sex, male and female
								respectively. Each element being specified is separated by ';'
								(semicolon). Then, in the spreadsheet, the labelCategory for the
								example above would be</p>
							<p>
								<strong>labelCategory</strong> = sex;sex:male;sex:female
							</p>
							<p>
								<strong>category</strong> = S;S:M;S:F
							</p>
							<p>and the matchings are sex to S; sex:male to S:M and
								sex:female to S:F.</p>
						</div>
						<div class="alert alert-warning">
							<img th:src="@{resources/img/warning.png}" /><span th:utext="#{process.file.text6}"><strong>Note </strong>
							It is extremely important that both labelCategory and category
							fields contain the elements in the same order otherwise they
							won't be associated correctly when generating the categories in
							the repository.</span>
						</div>
						<h4 th:text="#{process.file.subtitle3}">Relationship information</h4>
						<p th:utext="#{process.file.text7}">The third type of information is relationship information
							that is used to link resources and express the semantics of their
							relationship. This type of information is both when visualising
							the collection elements and when sharing data. Useful uses of
							these relationships include linking transcriptions with their
							associated audio/video file; linking documentation such as notes
							with specific analysis documents, etc. The following table
							summarises the types of relationships that can be included in the
							collection. While the other types of documentation - analytical
							and data level documentation - are included via the spreadsheets,
							the relationship information has to be included manually once all
							the resources for the collection have been stored in the
							repository. To facilitate this process it is important to use
							appropriate titles for the resources that enable to identifying
							them easily, e.g. &quot;Interview 1, teacher-1 date (transcript)&quot;. In
							the context of this application, analytical information - and
							relationship information - is key to enrich a qualitative
							collection, and the ways in which collection information can be
							displayed.</p>
						<table th:utext="#{process.file.table3}" class="table">
							<tr>
								<th>Element</th>
								<th>Description</th>
								<th>Example</th>
							</tr>
							<tr>
								<td>isFormatOf</td>
								<td>This relationship is useful when expressing that a
									resource is a different representation of another resource.
									This is particularly useful when describing the relationship
									between a transcript and an audio file. The transcript is a
									textual representation of the audio file</td>
								<td>A transcript<strong> isFormatOf</strong> an audio file
								</td>
							</tr>
							<tr>
								<td>isLinkedTo</td>
								<td>Generic relationship to express that two resources are
									related</td>
								<td>An image <strong>isLinkedTo</strong> a document
								</td>
							</tr>
							<tr>
								<td>isVersionOf</td>
								<td>This relationship is useful to relate the different
									versions of the same resource</td>
								<td>draft 0.2 <strong>isVersionOf</strong> draft 0.1
								</td>
							</tr>
							<tr>
								<td>isRelatedTo</td>
								<td>More generic relationship to express that two resources
									are related</td>
								<td>a Picture <strong>isRelatedTo</strong> a document
								</td>
							</tr>
							<tr>
								<td>isAnnotationOf</td>
								<td>This relationship is used to associate annotations with
									resources: memos with documents, code and categories with
									analysis documents, etc.</td>
								<td>A memo <strong>isAnnotationOf</strong> a document
								</td>
							</tr>
							<tr>
								<td>isReferencedBy</td>
								<td>Relationship to express that a resource is referred to
									in another resource. This is useful when linking external
									publications to documents within a research collection</td>
								<td>A publication <strong>isReferencedBy</strong> the
									research design document
								</td>
							</tr>
						</table>
					</div>
					<div class="tab-pane fade" id="example">
						<h3 th:text="#{process.page.subtitle3}">How-to Example</h3>
						<p th:text="#{process.text4}">Creating a spreadsheet involves
							the following steps:</p>
						<ul>
							<li th:text="#{process.page.li5}">Select the type of
								spreadsheet: Collections/Sub-collections or Files spreadsheet.</li>
							<li th:text="#{process.page.li6}">Adding description headers
								to the spreadsheet.</li>
							<li th:text="#{process.page.li7}">Generate spreadsheet,
								which will include at least all the QuDex mandatory fields.</li>
						</ul>
						<h4 th:text="#{process.page.subtitle4}">Select the type of
							spreadsheet</h4>
						<p th:text="#{process.text5}">In this example we are creating
							a QuDex file-level spreadsheet, which used the following Metadata
							Schemas:</p>
						<ul>
							<li th:text="#{process.page.li8}">Special Qudex Schema. For
								those Qudex specific fields that do not have their equivalent in
								other standard schemas</li>
							<li th:text="#{process.page.li9}">Dublin Core. For those
								Qudex fields that can be mapped to Dublin Core elements</li>
							<li th:text="#{process.page.li10}">W3C WGS84 lat/long
								Vocabulary. Used to describe locations by place, or
								latitude/longitude pairs</li>
							<li th:text="#{process.page.li11}">RDF Vocabulary. To
								specify the type of object we are describing</li>
							<li th:text="#{process.page.li12}">Fedora Relationships
								Ontology. To specify to which collection the document created
								belongs to. Note that the collections objects have to be
								described and stored in Fedora first</li>
						</ul>
						<p th:utext="#{process.text6}">1. Once we have started the
							process, the first window that appears is &#39;Type of
							spreadsheet selection&#39;. From here we will select the
							&quot;Files spreadsheet&quot; and click on &#39;Go to Metadata
							Configuration&#39;</p>
						<p>
							<a th:text="#{process.link1}"
								href="javascript:popitup('/swf-qudex-spreadsheet/resources/img/selectSS.png')">View
								screenshot</a>
						</p>
						<h4 th:text="#{process.page.subtitle5}">Metadata Selection</h4>
						<p th:utext="#{process.text7}">
							2. Now we are in the <b>&quot;Metadata Selection&quot;</b> screen
							and in the left hand side menu we can see that we have already
							some metadata fields selected. To ease the process, all the
							elements needed (optional and mandatory have been selected). Now,
							one can go to a specific schema and delete those optional
							elements that are not needed, if that is the case. If not, we
							could go directly to the &#39;Review section&#39;
						</p>
						<p>
							<a th:text="#{process.link1}"
								href="javascript:popitup('/swf-qudex-spreadsheet/resources/img/selectMD.png')">View
								screenshot</a>
						</p>
						<p th:text="#{process.text8}">2.1 If we want to include all
							the fields, then we can jump directoy to the review section.</p>
						<p th:utext="#{process.text9}">2.2 If we want to deselect
							metadata elements from particular vocabularies, we then have to
							select the desired schema and the click on &#39;Select Metadata
							Elements&#39;</p>
						<p th:utext="#{process.text10}">From the &#39;metadata
							elements selection&#39; screen we can select/deselect only
							optional elements since the mandatory elements need to present in
							order to generate valid Qudex spreadsheets</p>
						<p>
							<a th:text="#{process.link1}"
								href="javascript:popitup('/swf-qudex-spreadsheet/resources/img/md-elements-selection.png')">View
								screenshot</a>
						</p>
						<h4 th:text="#{process.page.subtitle6}">Review and Generate
							spreadsheet</h4>
						<p th:text="#{process.text11}">Two different actions could be
							performed form here:</p>
						<ul>
							<li th:text="#{process.page.li13}">Review the metadata
								headers included in the spreadsheet so far. At this point, you
								could always go back and delete or add new elements.</li>
							<li th:text="#{process.page.li14}">Generate Spreadsheet.
								This step involves validating and generating the spreadsheet.</li>
						</ul>
						<p th:text="#{process.text12}">The last step, once reviewed
							the headers included, will be to generate the spreadsheet. Then a
							dialog will appear to either save the file or open it.</p>
						<p>
							<a th:text="#{process.link1}"
								href="javascript:popitup('/swf-qudex-spreadsheet/resources/img/reviewMD.png')">View
								screenshot</a>
						</p>
						<p th:text="#{process.text13}">To start the process again and
							clean the all headers we have to click the 'Start new
							spreadsheet' button.</p>
						<a th:text="#{process.link2}"
							href="/swf-qudex-spreadsheet/resources/img//how-to.pdf"
							th:href="@{/resources/img//how-to.pdf}" target="_blank">Download
							the How-to in PDF</a><br /> <br />
					</div>
					<a id="load" class="btn btn-primary" th:text="#{process.link3}"
						href="/swf-qudex-spreadsheet/metadata">Start Spreadsheet
						creation </a>
				</div>
				<!-- DIV TAB-CONTENT -->
			</div>
		</div>
		<div class="modal js-loading-bar">
			<div class="modal-dialog">
				<div class="modal-content">
					<div class="modal-body">
						<h4 th:text="#{metadata.progressTitle}">Loading Schemas</h4>
						<div class="progress progress-striped active">
							<div class="progress-bar progress-bar-info" th:role="progressbar"
								th:aria-valuenow="100" th:aria-valuemin="0"
								th:aria-valuemax="100" style="width: 100%;"></div>
						</div>
						<span id="pbtext" class="hide" th:text="#{metadata.pbMessage}">Loading
							metadata schemas...</span>
					</div>
				</div>
			</div>
		</div>
		<div id="footer" th:include="fragments/footer :: footer"></div>
	</div>
	<script>
		$(document)
				.ready(
						function() {
							$('.js-loading-bar').modal({
								backdrop : 'static',
								show : false
							});

							$('#load')
									.click(
											function() {
												var $modal = $('.js-loading-bar'), $bar = $modal
														.find('.progress-bar');
												$modal.modal('show');
												$bar.text($('#pbtext').text());
												$bar.addClass('animate');
											});
						});
	</script>
</body>
</html>